Disk arrays may include groups of physical disks that are logically bound together to represent contiguous data storage space for applications. For example, disk arrays may be divided into redundant array of inexpensive disks (RAID) groups, which are disk arrays created by logically binding individual physical disks together to form the RAID groups. RAID groups represent a logically contiguous address space distributed across a set of physical disks. Each physical disk is subdivided into pieces used to spread the address space of the RAID group across the group (along with parity information if applicable to the RAID level). The physically contiguous pieces of the physical disks that are joined together to create the logically contiguous address space of the RAID group are called stripes. Stripes may form blocks and blocks may be allocated to create logical representations of storage space for use by applications within a system.
Applications access and store data incrementally by use of logical storage array partitions, known as logical units (LUNs). LUNs are made up of collections of storage blocks of a RAID array and are exported from the RAID array for use at the application level. LUNs are managed for use at the application level by paired storage processors (SPs). Ownership of a LUN is determined when the LUN is mounted by the application, with one of the paired SPs designated as the owner SP and the other SP acting as a backup processing device for the first.
LUNs may be duplicated by copying the contents of a source LUN to another LUN including new storage blocks, thereby creating a new LUN that is a duplicate of the source LUN (e.g., a clone). Clones may be used for archival purposes, such as point-in-time backups, and for restore points in the event of system failures or in order to retrieve older data. Data referenced by a source LUN or by a clone (when the clone is not used as a restore point) may change over time. These changes may be tracked by the use of bitmaps, known as delta maps or fracture logs, and configuration information. Delta maps are bitmaps that may track changed blocks by use of a bit associated with each physical storage data area referenced by a LUN. Configuration information may track processing objectives between a source LUN and a clone. For example, within a clone group, which includes a source LUN and related clones, configuration information may be used to identify synchronization processing activities between a clone or set of clones and a source LUN within the clone group.
Ownership of a LUN may change under a variety of circumstances. For example, ownership of a LUN may migrate from one SP to another for host load balancing reasons, for host failover events, for SP failures, and for manual trespass operations initiated by a user at an application level. Further, entire clone groups traditionally trespass together from one SP to another. The term “trespass,” as used herein, refers to a change of association of a clone group from one SP to another SP.
In conventional systems, when ownership of a LUN migrates from one SP to the paired SP, data structures (e.g., delta maps) and configuration information for each LUN that is migrated are required to be communicated between the SPs. However, these data structures are not required for the change in ownership/association to occur. This information communication has traditionally been required to be completed prior to accessing a migrated LUN for input and output (I/O) operations. Accordingly, a migrating LUN is not useable for I/O purposes. Under some of the above-described circumstances where ownership may change, such as during a host failover event or an SP failure, many LUNs may need to be migrated from an owner SP to the paired SP. Under these circumstances, the time required for communicating delta map and configuration information for a migrating LUN may be lengthy due to I/O bandwidth limitations, resulting in degraded I/O performance.
Synchronization between a source LUN and a clone may occur either periodically or upon request from the application level or a system administrator. On conventional systems, synchronization requires a separate communication of data structures and configuration information between the original owner SP and the paired SP. Accordingly, conventional systems, in addition to imposing an unavailability associated with a trespass operation, also duplicate communication of delta maps and configuration information between original owner SPs and the paired SPs when a synchronization event follows a trespass operation. As well, certain configuration information that was transmitted during a trespass operation is only needed during a synchronization event. Accordingly, much of the communication bandwidth associated with a trespass operation is unnecessary in conventional systems.
Accordingly, in light of these difficulties associated with conventional trespass of LUNs, there exists a need for improved methods, systems, and computer program products for postponing bitmap transfers and eliminating configuration information transfers during trespass operations in a disk array environment.